Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/uucp/protocol/wegrzyn.paper

Internet Message Format | 1991-08-18 | 14.0 KB

Path: clarkson!rpi!usc!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!ucsd!nosc!crash!simpact!cmkrnl!jeh
From: [e-mail]
Newsgroups: comp.mail.uucp
Subject: Re: G protocol (Wegrzyn paper)
Message-ID: <[e-mail]>
Date: 4 Aug 91 23:06:19 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Kernel Mode Consulting, San Diego CA
Lines: 449

The paper on the "G" Protocol which I just posted references articles
by Greg Chesson and Chuck Wegrzyn.  Here is the one by Wegrzyn.

    --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG
Internet:  [e-mail], [e-mail], or [e-mail]
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh


This is the second issue; the information below is the start of
what has been collected here.  It is expected that more information
will be collected in the next few weeks, and that information will
be forwarded when/if it becomes available.

 =====================================================
 -- part 1
 =====================================================
This information came via several people, most of whom snet this
exact message (probably from their news archives from before we
joined the net):

    I am posting this over the network because I believe that
    others are interested in knowing the protocols of UUCP.
    Below is listed all the information that I have acquired
    to date. This includes the initial handshaking phase, though
    not the login phase. It also doesn't include information
    about the data transfer protocol for non-packet networks
    (the -G option left off the uucico command line). But, just
    hold on - I am working on that stuff.

    For a point of information : the slave is the UUCP site being
    dialed, and the master is the one doing the calling up. The
    protocols listed in the handshaking and termination phase are
    independent of any UUCP site : it is universal. The stuff in
    the work phase depends on the specific protocol chosen. The
    concepts in the work phase are independent of protocol, ie. the
    sequences are the same. It is just the lower level stuff that
    changes from protocol to protocol. I have access only to level
    g and will document it as I begin to understand it.

    Most of the stuff you see here is gotten from the debug phase
    of the current BSD UUCP system.

    I hope this is useful. Maybe this will get some of the real
    'brains' in UUCP to get off their duffs and provide some real
    detail. In any case, if you have any questions please feel
    free to contact me. I will post any questions and answers over
    the network.


                Chuck Wegrzyn
                {allegra,decvax,ihnp4}!encore!wegrzyn

                [phone]



            UUCP Handshake Phase
            ====================

Master                            Slave
------                            -----

                    <-----        \020Shere\0     (1)


(2)  \020S<mastername> <switches>\0    ----->


                    <-----        \020RLCK\0      (3)
                            \020RCB\0
                            \020ROK\0
                            \020RBADSEQ\0

                    <-----        \020P<protos>\0 (4)


(5) \020U<proto>\0            ----->
    \020UN\0


(6) ...


(0) This communication happens outside of the packet communication that
    is supported. If the -G flag is sent on the uucico line, all
    communications will occur without the use of the packet
    simulation software. The communication at this level is just
    the characters listed above.

(1) The slave sends the sequence indicated, while the master waits for
    the message.

(2) The slave waits for the master to send a response message. The message
    is composed of the master's name and some optional switches.
    The switch field can include the following

            -g        (set by the -G switch on the
                     master's uucico command line.
                     Indicates that communication
                     occurs over a packet switch net.)
            -xN        (set by the -x switch on the
                     master's uucico command line.
                     The number N is the debug level
                     desired.)
            -QM        (M is really a sequence number
                     for the communication.)

    Each switch is separated from the others by a 'blank' character.

(3) The slave will send one of the many responses. The meanings appear to
    be :

    RLCK

        This message implies that a 'lock' failure occurred:
        a file called LCK..mastername couldn't be created since
        one already exists. This seems to imply that the master
        is already in communication with the slave.

    RCB

        This message will be sent out if the slave requires a
        call back to the master - the slave will not accept a
        call from the master but will call the master instead.

    ROK

        This message will be returned if the sequence number that
        was sent in the message, attached to the -Q switch, from
        the master is the same as that computed on the slave.

    RBADSEQ

        Happens if the sequence numbers do not match.

    (Notes on the sequence number - if a machine does not keep
     sequence numbers, the value is set to 0. If no -Q switch
     is given in the master's line, the sequence number is
     defaulted to 0.

     The sequence file, SQFILE, has the format

        <remotename> <number> <month>/<day>-<hour>:<min>

     where <remotename> is the name of a master and <number>
     is the previous sequence number. If the <number> field
     is not present, or if it is greater than 9998, it is
     set to 0. The <number> field is an ascii representation
     of the number. The stuff after the <number> is the time
     the sequence number was last changed, this information
     doesn't seem important.)

(4) The slave sends a message that identifies all the protocols that
    it supports. It seems that BSD supports 'g' as the normal case.
    Some sites, such as Allegra, support 'e' and 'g', and a few
    sites support 'f' as well. I have no information about these
    protocols. The exact message sent might look like

        \020Pefg\0

    where efg indicates that this slave supports the e,f and g
    protocols.

(5) The slave waits for a response from the master with the chosen
    protocol. If the master has a protocol that is in common the
    master will send the message

        \020U<proto>\0

    where <proto> is the protocol (letter) chosen. If no protocol
    is in common, the master will send the message

        \020UN\0

(6) At this point both the slave and master agree to use the designated
    protocol. The first thing that now happens is that the master
    checks for work.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

            UUCP Work Phase
            ===============


Master                            Slave
------                            -----

(a) Master has UUCP Work

    (1) X file1 file2     ----->

                    <-----        XN        (2)
                            XY

    When the master wants the slave to do a 'uux' command
    it sends the X message. If the slave can't or won't
    do it, the slave will send an XN message. Otherwise
    it will send an XY message.

(b) Master wants to send a file

    (1) S file1 file2 user options  ----->

                    <-----        SN2        (2)
                            SN4
                            SY

            <---- <data exchanged>---->            (3)


                    <-----        CY        (4)
                            CN5

    If the master wishes to send a file to the slave, it will
    send a S message to the slave. If the slave can or will do
    the transfer, it sends a SY message. If the slave has a
    problem creating work files, it sends a SN4 message. If
    the target file can't be created (because of priv's etc)
    it sends a SN2 message.

    The file1 argument is the source file, and file2 is the
    (almost) target filename. If file2 is a directory, then
    the target filename is composed of file2 concatenated
    with the "last" part of the file1 argument. Note, if the
    file2 argument begins with X, the request is targeted to
    UUX and not the normal send.

    The user argument indicates who, if anyone, is to be notified
    if the file has been copied. This user must be on the slave
    system.

    I am not sure what the options argument does.

    After the data has been exchanged the slave will send one of
    two messages to the master. A CY message indicates that every-
    thing is ok. The message CN5 indicates that the slave had
    some problem moving the file to it's permanent location. This
    is not the same as a problem during the exchange of data : this
    causes the slave to terminate operation.

(c) Master wishes to receive a file.

    (1) R file1 file2 user    ----->

                        <-----    RN2        (2)
                            RY mode

    (3)        <---- <data exchanged> ---->

    (4)    CY        ----->
        CN5

    If the master wishes the slave to send a file, the master sends
    a R message. If the slave has the file and can send it, the
    slave will respond with the RY message. If the slave can't find
    the file, or won't send it the RN2 message is sent. It doesn't
    appear that the 'mode' field of the RY message is used.

    The argument file1 is the file to transfer, unless it is a
    directory. In this case the file to be transferred is built
    of a concatenation of file1 with the "last" part of the file2
    argument.

    If anything goes wrong with the data transfer, it results in
    both the slave and the master terminating.

    After the data has been transferred, the master will send an
    acknowledgement to the slave. If the transfer and copy to the
    destination file has been successful, the master will send the
    CY message. Otherwise it will send the CN5 message.

(d) Master has no work, or no more work.

    (1) H            ----->

                <-----                HY    (2)
                                HN

    (3) HY            ----->

                <----                HY    (4)

    (5) ...

    The transfer of control is initiated with the master sending
    a H message. This message tells the slave that the master has
    no work, and the slave should look for work.

    If the slave has no work it will respond with the HY message.
    This will tell the master to send an HY message, and turn off
    the selected protocol. When the HY message is received by the
    slave, it turns off the selected protocol as well. Both the
    master and slave enter the UUCP termination phase.

    If the slave does have work, it sends the HN message to the
    master. At this point, the slave becomes the master. After
    the master receives the HN message, it becomes the slave.
    The whole sequence of sending work starts over again. Note,
    the transmission of HN doesn't force the master to send any
    other H messages : it waits for stuff  from the new master.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


            UUCP Termination Sequence
            =========================

 Master                                Slave
 ------                                -----

 (1) \020OOOOOO\0        ----->

                <-----            \020OOOOOOO\0 (2)



    At this point all conversation has completed normally.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

            UUCP Data Transfers
            ===================

    After the initial handshake the systems send messages in one
    of two styles : packet and not packet. A Packet protocol is
    just raw data transfers : there is no protocol or acknowledgements;
    this appears to assume that the lower level is a packet network
    of some type. If the style is not Packet, then extra work is
    done. I am still working on this stuff.

 =====================================================
 -- part 2
 =====================================================
 ** summary of UUCP packets **
(this is much like part 1, but shortened and compared against a
live UUCP ~uucp_adm/uucico)

note that all transmissions end with a null, not shown here


(master)        (slave)

 ... dials up ...    <DLE>Shere        says "hello"

<DLE>S<sysname> <opts>                says who he is

        |    <DLE>ROK        says ok to talk
        |    <DLE>RLCK        says locked out
        |    <DLE>RCB        says will call back
        |    <DLE>RBADSEQ        says bad seq num

            <DLE>P<protos>        what protocols he has

<DLE>U<proto>    |                which to use
<DLE>UN        |                use none, hang up


packet driver is turned on at this time, if not told otherwise

 -- if master has work --

to sned file to slave...
S <mfilenm> <sfilenm> <user> <opts>        request to sned file

        |    SY            ok -- i'll take it
        |    SN2            not permitted
        |    SN4            can't make workfile

<data>                        the file is transmitted

        |    CY            finished OK
        |    CN5            can't move into place


to recv file from slave...
R <sfilenm> <mfilenm> <user>            request to recv file

        |    RY<mode>        ok -- here is prot mode
        |    RN2            not permitted

            <data>            file is transmitted

CY        |                worked
CN5        |                can't move into place


to do UUX on slave...
X <file1> <file2>                request to exec file

        |    XY            ok -- will do
        |    XN            nopers

to indicate that he has no more work...
H                        no more work

        |    HN            reverse roles
        |    HY            no work here either

to accept slave's claim of no more work...

HY                        agrees to hang up

the rest of the hang-up is done OUTSIDE of packet driver
<DLE>OOOOOO                    signs off (6*'O')

            <DLE>OOOOOOO        signs off (7*'O')


If the slave has work, then the roles are reversed, and the
session proceeds from the label 'loop1' above.  The system
which was the slave is now the master, and the old master is
just the slave.

The <opts> which follow the system name for the start-up sequence
include:
    -g        don't use packet driver (command line -G)
    -xN        debug level (command line -Xn)
    -QN        seq number (if systems use this)

The filenames for <mfilenm> should be complete filenames with
path information; otherwise they are assumed to be in /usr/spool/uucp.
The filenames for <sfilenm> should be either complete filenames
or directory names.  If directory names are used, then the final
componant of <mfilenm> is appended to form the complete filename.

The 'X' command to do UUX on a slave is more than a little unclear.
It doesn't seem to work here, but that may be a microsoft "feature".


Protocol "g", which seems to be the one most commonly used, is supposed
to be a slightly munged version of level 2 of X.25; an article was just
posted in net.unix-wizards (which you probably have already seen) to
this effect.  The article didn't provide any details on the protocol,
but merely mentioned the modifications.

The "packet" mode, with no protocol, does not work under microsoft
implementations, and may have *lots* of trouble working anywhere
else as well.  It evidently requires that zero-length reads happen
every so often to delimit things, such as files being transferred.
This of course can't happen without the packet driver, which was long
gone by the time sys-3 or sys-5 or <your current version> came along.

**********************************
** end of issue #2
**********************************

(end)